Choosing a Non-Validating Parser

As was mentioned before, choosing your toolset is a personal matter.  There are a number of really good parsers out there to choose from.  The following are some resources that you can go to on the Internet to download tools and learn about different resources available.

The Expat non-validating parser is one of the nicest parsers around.  It is a command line tool that is very simple to use and basic to understand.  It also includes source code.  You can download it for free at ftp://ftp.jclark.com/pub/xml/expat.zip.

The TclXML parser is available at http://www.zveno.com/zm.cgi/in-tclxml/. This non-validating parser is cross platform and is very robust.

Finally, James Tauber’s XmlSoftware.com (http://www.xmlsoftware.com/parsers/) is the definitive source for finding both validating and non-validating parsers.  This is the place to go to start looking at what is available and putting together your XML tool chest.
 
Valid Documents

You have seen two types of XML documents thus far: those that have DTD’s, and those that do not.  XML documents that do have DTD’s appear to have very few restrictions.  You can add elements and attributes at will without regard to structure as a whole.  The only thing that you have to worry about is that the document is syntactically correct.  This being the case, you might question the need for DTD’s at all.  Actually, not having a DTD in your document puts significant restrictions on your document as regards validity.

If you want an XML document to be valid, but do not want to have a DTD associated with it, the following rules must be adhered to:

All the attribute values in the document must be specified;  there can be no default values.  This makes sense because default values are specified in the DTD.

There can be no references to internal entities in the DTD except those that are predefined in the XML specification (i.e. &lt;, &gt, &apos;, &quot;).  Again, this makes sense because internal entities are defined in the DTD.

There can be no attributes that are subject to normalization (contain entity references).

In elements with content consisting of only elements, there can be no white-space (e.g. space, tab, etc.) between the starting tag and the content of the first element.  For example, the following would be illegal:
    <el1>   <el2>data</el2></el1>

As you can see, the DTD goes along way to helping XML processors deal with your documents.

Tip:	It is very easy to create XML documents without going to the process of creating a DTD.  However, the time saved by not creating a DTD will often  be spent working around problems/errors that you did not account for.  

Make a habit of always using a DTD.  Even for simple documents.  It makes them easier to create, readable and maintainable.   It also makes them easier to process by XML processors. 

Going through the process of validating your document is beneficial for a number of reasons.  None the least of which is making sure that the content within the document adheres to the structure defined in the DTD.  

Validation is Relative

Validating a given document requires an examination of the document’s DTD and then checking to make sure that the content contained therein matches that DTD.  DTD’s can be strict or loose.  Also, DTD’s don’t have much in the way of strict type checking.  What is considered valid depends on the content models that you create.  How you design your DTD will affect the rules of validation that are applied to the contents of the document.   This is a very important point.

Validating parsers are written in simple terms.  They understand the content model you define, they understand the element structure contained within the document, and that is it.  

Tip:	What you may consider valid in an XML document may have a different meaning to a validating parser.  It can only compare the DTD to the content that is defined in the document.  

Another way to look at is that validation checks the markup, but actually does little or nothing to check what’s between the markup (the content), other than look for more markup.

Validating parsers cannot provide much in the way of element content relationship, typos, and data integrity.  XML is not a like relational database in that way.  There are new additions to the XML standards that are being proposed that address some of these issues, but they are a ways off from being implemented.  Vendors such as Microsoft, Netscape and Sun are adding their own extensions to XML support within their products, but these are not portable.  Keep this in mind if you decide to use them.  These same vendors have done the same thing with HTML, and that is why there are many browser specific web sites on the Internet today.  Vendor specific technologies is the antithesis of what XML is all about!

Validating Parsers

Like non-validating parsers, there are a number of validating parsers that are available for free download.  As mentioned before, the James Tauber’s XmlSoftware.com (http://www.xmlsoftware.com/parsers/) is the first place you may want to go to find a list of parsers that can be downloaded for free.

Final Words on Well-Formedness and Validity

It is easy to create well-formed XML documents if you take the proper measures in the beginning.  Creating a DTD to define a concise content model is the first step.  Syntactically defining the DTD is not the difficult part.  Creating a logical content model that supports the data that you are storing is where it can get difficult.  However, this is not a new problem.  It is the same for database administrators as it is to application developers.  Structuring the data so that it supports all possible cases that your software may face is an art.

In conclusion, always check to make sure that your documents are well-formed and valid.  This will allow XML processors to deal with the document in the way that is intended.  Get in the habit of always creating a DTD for your documents, no matter how simple they are (remember, it is always the simple ones that grow and become complex).  Use a non-validating parser to check to make sure that your document is well-formed.  Then use a validating parser to check for validity.   It is often a good idea to have a couple of different types of these at your disposal.  

Another way to create well-formed and valid documents is to use an XML editor that validates while you are creating the document.  There are a few XML editors out there (like Microsoft XML Notepad), but they have a long way to go before they are truly useful.  The standard Window’s Notepad and the Microsoft Visual InterDev development environment are still the editors of choice for many.